1. Field of the Invention
The present invention relates to a method and apparatus for providing a multimedia message service using a Parlay X Web service, which enables a multimedia messaging application server to easily check the status of a multimedia message which is requested to be transmitted.
2. Description of the Related Art
The Parlay X Web service technology provides a standardized interface between an application service layer and a transmission layer of a communication network in order to enable a third party to provide services to users not by being bound to a specific communication network but by using the capability of the communication network, such as wired/wireless call control function, short message service (SMS) and multimedia message service (MMS) transmission/reception function, and positioning of a particular subscriber.
FIG. 1 shows a structure of an open-type service platform based on Parlay X Web service. The open-type service platform includes a Parlay gateway 20 which functions as a sort of middleware between an application server 10 and a wired/wireless communication network 30. The application server 10 provides a predetermined service to users by using the capability of a communication network, and the wired/wireless communication network 30 has its own communication network capability and resources. With the Parlay X gateway 20, the application server 10 is not bound to a specific communication network and provides the service by using the resources of the wired/wireless communication network 30.
The Parlay X gateway 20 has its Service Capable Feature (SCF) in connection with corresponding network resources according to the level of communication network capability and has Application Programming Interface (API) function set up according to the provided service. When the application server 10 calls for an API function, the API function operates and cooperates with network resources of the communication network 30. The SCF includes a short message service (SMS) SCF, a multimedia message service (MMS) SCF, a telephone call connection (TPC) SCF, and a presence SCF for processing status information of a particular user.
The open-type service platform is suggested by a Parlay group and made public as specifications of the 3GPP, ETSI and 3GPP2 by the 3rd Generation Project Partnership (3GPP), which is a substantial standard group for the third mobile communication, through a Joint Working Group (JWG) activity.
Recently, the 3GPP and the Parlay Group are standardizing Parlay X MM API related to a multimedia message service for transmitting/receiving a multimedia message to/from a mobile terminal. The multimedia message is a message combined with music, moving picture, image and/or text. At present, the 3GPP Transport Stream (TS) 29. 119-5 v6.3.0 is suggested as a standard document.
According to the standard document, a Parlay X MM API defined in the standard document can be called remotely between the application server using a multimedia message service and the Parlay X gateway through a Simple Object Access Protocol (SOAP) message.
FIG. 2 shows a signal flow in the multimedia message transmission procedure based on the 3GPP TS29. 119-5 v6.0.0.
Referring to FIG. 2, at step S101, the application server 10 includes a multimedia message to be transmitted into a multimedia message send message request, i.e., SendMessage Request, and transmits the multimedia message SendMessage Request including the multimedia message to the Parlay X gateway 20 to transmit the multimedia message through a communication network.
At step S102, the Parlay X gateway 20 receives the multimedia message SendMessage Request and generates a string-type MM reference identification value for identifying the multimedia message, i.e., ReferenceID. At step S103, puts the MM ReferenceID into a response message, i.e., SendMessage Response, and transmits the SendMessage Response to the application server 10 to thereby notice that the Parlay X gateway 20 has received the multimedia message SendMessage Request.
The application server 10 uses the MM ReferenceID to perform a subsequent process for the multimedia message such as checking the delivery status and canceling transmission.
At step S104, the Parlay X gateway 20 requests to transmit the multimedia message to a user terminal 40 by transmitting the multimedia message requested to be transmitted through an MM7_Submit_REQ message of an MM7 Protocol, which is a protocol defined in a multimedia message service (MMS) server 31 which provides a multimedia message service in the communication network 30.
At step S105, the Parlay X gateway 20 sets up a DeliveryStatus value at a waiting mode, i.e., MessageWaiting. The DeliveryStatus value indicates the delivery status of the multimedia message until the MM7_Submit_RES message from the MMS server 31.
Herein, the MMS server 31 which has received the MM7_Submit_REQ message extracts a multimedia message to be transmitted and a destination thereof by analyzing the MM7_Submit_REQ message, transmits the multimedia message to the user terminal 40, puts a multimedia message delivery result in the MM7_Submit_RES message, and transmits the MM7_Submit_RES message with the a multimedia message delivery result to the Parlay X gateway 20, at step S108.
At step S109, the Parlay X gateway 20 sets up a DeliveryStatus value at ‘Delivered,’ when the status value included in the received MM7_Submit_RES message indicates ‘transmission succeeded’; or it sets up a DeliveryStatus value at ‘DeliveryImpossible,’ when the status value included in the received MM7_Submit_RES message indicates ‘transmission failed.’
In the above-described transmission of a multimedia message, the application server 10 using the multimedia message transmission transmits a message requesting for the delivery status, i.e., GetMessageDeliveryStatus Request message, to the Parlay X gateway 20 at every moment when delivery status information is needed in order to acquire delivery status information of a multimedia message at steps 106 and 110. Herein, the GetMessageDeliveryStatus Request message uses an MM ReferenceID included in a SendMessage Response with respect to a transmission request received before as its parameter at steps 106 and 110.
At steps 107 and 110, the Parlay X gateway 20 puts a DeliveryStatus value corresponding to the MM Reference ID, that is, one among ‘MessageWaiting,’ ‘Delivered’ and ‘DeliveryImpossible,’ into the GetMessageDeliveryStatus Response and transmits the GetMessageDeliveryStatus Response to the MM application server 10. ‘MessageWaiting’ is transmitted as the DeliveryStatus vale until the Parlay X gateway 20 receives the MM7_Submit_RES message from the MMS server 31. After the Parlay X gateway 20 receives the MM7_Submit_RES message from the MMS server 31, ‘Delivered’ or ‘DeliveryImpossible’ is transmitted according to a delivery result included in the MM7_Submit_RES message.
The application server 10 can check out the delivery status of a multimedia message it has requested from the DeliveryStatus value included in the received GetMessageDeliveryStatus Response.
According to the conventional technology, the application server 10 should inquire the Parlay X gateway 20 for the delivery status of a message repeatedly to know whether a multimedia message requested to be transmitted is transmitted successfully or not, until it acquires ‘Delivered’ or ‘DeliveryImpossible.’
Therefore, if the transmission of MM7_Submit_REQ message or MM7_Submit_RES message is delayed between the Parlay X gateway 20 and the MMS server 31 or if transmission process of a corresponding multimedia message is delayed in the Parlay X gateway 20 or the MMS server 31 due to a great deal of messages or overload, the application server 10 transmits many GetMessageDeliveryStatus Request messages to the Parlay X gateway 20 and the Pariay X gateway 20 transmits many GetMessageDeliveryStatus Response messages. This causes wasteful use of resources and loads on both application server 10 and the Parlay X gateway 20 unnecessarily.